In IT environments it is customary for a plurality of software developers and/or administrators to work with a particular computing system. For example, many software projects are too large for a single developer, and thus there are a plurality of developers writing the source code for such projects. In such environments, measures must be taken to avoid conflicts between two or more developers. In particular, source code is usually divided into a plurality of source files, and thus only one developer should be able to work on a given component/source file at a time. Otherwise, two or more developers could simultaneously make changes to the same portion of the source code, and when these developers save the changes to permanent storage (e.g., disk), only the changes made by one of these developers would actually be stored. Consequently, it is standard practice to use a software configuration management system, in which developers must “check out” a particular source file before they can make changes to the file. Once checked out, the source file becomes “locked” in the configuration management system, and accordingly no other person can check out the file to make changes until the developer who checked out the file checks the file back in.
Furthermore, modem software engineering practice often involves a formal process for making software changes, since haphazard changes can potentially introduce bugs or adversely affect the functionality of the overall software. Accordingly, a developer or team of developers typically must submit a formal request before actually performing changes to the software. Such “change requests” typically describe desired behavioral changes to the system (referred to as figurative changes), and identify exactly what will be changed in which files (literal changes) to accomplish the proposed change in functionality. Change requests are typically submitted to a designated group of individuals with the authority to review the proposed change, and approve or reject the change. This designated group, often referred to as a review board, commonly comprises an administrator and a plurality of subject matter experts.
Two problems can occur in such an environment. First, the approved change can be performed improperly (e.g., a developer may change a file that was not specified in the change request). Second, a developer could circumvent the approval process and make changes without ever submitting a change request. (It is not uncommon for developers to view the process of change requests as a “hassle”.) In either case the potential for total system failure can be very large, and it can be very difficult if not impossible to identify the cause of failures due to such undocumented changes.